# <a href="https://infostart.ru/1c/articles/1253148/" target="_blank">Находим взаимопонимание с заказчиками с применением Enterprise Architect</a>

Enterprise Architect – мощное средство моделирования бизнес-процессов и информационных систем. Сергей Наумов на мастер-классе конференции Infostart Event 2019 Inception показал, как моделировать бизнес-процессы и составлять понятные заказчику документы при внедрении 1С-систем с помощью Enterprise Architect. Материалы мастер-класса будут полезны как разработчикам на платформе 1С, так и аналитикам, участвующим во внедрении.
Я хочу рассказать, как можно упростить себе жизнь на проекте, применяя Enterprise Architect в качестве инструмента моделирования. Чтобы и заказчикам было понятнее, что вы собираетесь для них делать, и вам было проще понять, чего от вас хотят.

Про моделирование на UML я рассказывал пару лет назад. Сейчас я опять вернусь к этой теме, но теории будет очень мало – будет в основном практика.

## Зачем заниматься моделированием?

![](_src/2dd7bd781bfea06ceccbbafc1cc93ded.png)

Системы моделирования в нашей отрасли в основном применяют, чтобы объяснить исполнителям, как сделать так, чтобы результат их труда максимально соответствовал ожиданиям заказчика. Также чтобы описать бизнес-процессы – как они превратятся в объекты данных, как требования трассируются до конечных результатов.

Но для меня моделирование – это не просто инструмент для процесса взаимодействия с заказчиком, для меня моделирование – это конкретный результат, который дает мне:

* сокращение трудозатрат на переделках (конкретные сэкономленные деньги, которые я положу себе в карман);
* упрощение передачи информации;
* когда вы делаете модель какой-то системы или какого-то объекта, вы, глядя на эту модель, можете понять, какие детали или нюансы вы упустили – потому что сложный объект зачастую трудно удержать в голове, и моделирование помогает не упустить детали;
*  и, конечно, будучи руководителем, я не могу не отметить, что человек может заболеть, уйти, уволиться и т.д. И когда есть модель, есть что-то, на чем новые специалисты могут обучиться и быстро погрузиться в процесс - привлечение новых специалистов очень упрощается.

![](_src/7f499d58beec2ccde8b1bd1e22fb5e64.png)

Давайте посмотрим на эту диаграмму. Что вы здесь видите? Это модель сказки «Репка».

Обратите внимание, что сама сказка «Репка» – это большой текст. А здесь в виде модели она представлена на небольшой диаграмме, которая передает весь смысл этой сказки.

Да, она более сокращенная, но, тем не менее, она дает вам представление об объекте и понимание того, о чем там речь – описывает всю последовательность действий.

Прочитав эту диаграмму, вы уже будете знать весь сценарий этой сказки.

## Модель

![](_src/e22512ca490d568cc339bfad908ad8a7.png)

Чтобы разобраться, что такое модель, мне нужно два добровольца из зала – Юрий и Сергей.

Вас, Сергей, я попрошу на минуту выйти за дверь. А для вас, Юрий, задача: вам нужно построить модель тыквы так, чтобы Сергей потом смог отгадать по модели, что это за предмет.

Модель нужна, чтобы находить взаимопонимание с заказчиком. При этом неважно, какую вы выберете нотацию описания. Изначально вы можете не знать, в какой нотации заказчику будет комфортнее воспринимать модель. Что такое нотация – мы сейчас рассмотрим.

Модель, в свою очередь, может быть текстовая или с помощью диаграммы – мы сейчас рассмотрим разные варианты.

| Характеристики (что это)                 | Вес – 1.5 кгЦвет – оранжевыйФорма – шарТип – овощ |
|------------------------------------------|------------------------------------------|
| <p style="box-sizing: border-box; margin: 0px 0px 10px;">Зачем оно (для чего)</p> | <p style="box-sizing: border-box; margin: 0px 0px 10px;">Для приготовления каши</p><p style="box-sizing: border-box; margin: 0px 0px 10px;">Для запекания</p><p style="box-sizing: border-box; margin: 0px 0px 10px;">Для еды</p> |
| <p style="box-sizing: border-box; margin: 0px 0px 10px;">Кто использует</p> | <p style="box-sizing: border-box; margin: 0px 0px 10px;">Люди</p> |

Смотрите, Юрий выбрал текстовую нотацию и выработал некие параметры, по которым теперь можно описать любой овощ и составить его модель.

Теперь вернем Сергея – пусть он попробует угадать, какой объект был замоделирован.

Вопрос – почему нельзя в модели сразу написать, что это тыква?

Когда вы составляете модель предприятия вы не можете написать, что это предприятие. Вам нужно сделать модель этого объекта. Тыква – это конкретный предмет, а предприятие мы одним словом описать не можем, не можем охарактеризовать весь процесс этого предприятия. О том, что это технологическое предприятие, вы напишете в отчете об обследовании в нескольких местах, но как вы опишете процессы? Словами описывать долго, быстрее сделать картинку.

Исключение составляют какие-то типовые процессы. Условно говоря, есть малая компания, у которой стандартный процесс выставления счета. Его можно не описывать.

А все процессы, построенные на основе типовых, но имеющие особенности, должны быть описаны. У меня сейчас есть проект в металлургии – там есть очень большие особенности с присадками, потому что присадки очень сильно меняют качество изделия. И необходимо указывать – кто какие присадки планирует для этой конкретной серии. Потому что у каждого заказчика свои потребности. И процесс уже получается большой.

Так вот, смотрите, что сделал Юрий. Он взял наш объект и выработал определенные проекции:

*  первая проекция – характеристика этого объекта;
*  вторая проекция – зачем это;
*  третья проекция – кто использует.

Он спроецировал объект реального мира «на бумагу». Точно так же мы можем взять наше предприятие (предприятие, которое является для нас предметом или объектом нашего моделирования) и разложить его по определенным осям:

*  оргструктура;
*  бизнес-процессы;
*  функции этого предприятия;
*  цели и т.д.

То, как мы раскладываем объект моделирования по осям – это нотация. Юрий изобрел нотацию описания овощей.

Модель в свою очередь – это набор диаграмм либо текстовых данных, описанная по этой нотации.

В свою очередь, диаграмма, которую мы будем применять – это конкретный рисунок, который изображает эту ось (мы наш объект как бы раскладываем по многим осям).

## Язык моделирования UML

![](_src/3e0a8b25bc6a9e474824f981b0cc2557.png)

Я применяю в своей практике UML – это очень удобный, на мой взгляд, язык для того, чтобы передавать знания.

Важно понимать, что UML – это не нотация, это язык. Он вам не объясняет, как разложить ваш объект по каким-то осям и как его представить. Язык UML – универсальный. В состав UML входит набор диаграмм, которые предназначены для описания разных аспектов поведения объекта либо его структуры.

*  структура объекта – это часть объекта;
*  а поведение – это как он действует или как он изменяется во времени.

## Применение UML для практического моделирования

Давайте рассмотрим пару примеров практического применения UML.

![](_src/fddd449fe77e02af6eeb05f16312aa78.png)

Начнем с диаграммы пакетов.

На слайде приведено стандартное определение из википедии, что такое диаграмма пакетов:

«Диаграммы пакетов унифицированного языка моделирования (UML) отображают зависимости между пакетами, составляющими модель».

Когда я читал, что это и для чего, мне было совсем непонятно. Ввиду того, что UML – очень универсальный язык, большинство книг (обычно переводных) оперируют примерно такими терминами, которые не дают представление, зачем это.

На самом деле все просто. Пакеты – это определенные группировки тех или иных проекций (бизнес-процессов, участников бизнес-процессов и т.д.)

Вам понятно, что изображено на картинке справа? Я применяю эту диаграмму так, как мне удобно, и это вполне соответствует нотации.

![](_src/a785d31c9d63b8fd2bd98edbdc6907aa.png)

Следующее определение – диаграмма вариантов использования. Это моя любимая диаграмма.

На некоторых форумах по UML годами продолжаются споры: «Что такое use case – функция или не функция?». Но мы с вами не будем разбираться – функция это или не функция: нет смысла тратить время как воинствующие теоретики на этих форумах. Для практического применения это не важно.

Давайте посмотрим определение:

«Диаграмма вариантов использования в UML – это диаграмма, отражающая отношение между авторами и прецедентами и являющаяся составной частью модели прецедентов, позволяющая описать систему не концептуальном уровне».

Я даже не буду читать это определение дальше – сразу видно, что оно неконструктивно.

На самом деле все очень просто:

* Use case – это сценарий, порядок действий, на выходе которого реализуется определенная цель или появляется определенная ценность (value).
* Цель, которую преследует автор (внешний по отношению к этому сценарию участник), или то, что он получит на выходе, обычно отражается в названии сценария.
* Частный случай сценария – это бизнес-процесс, у которого есть выход и есть заказчик, который что-то хочет от этого бизнес-процесса.

![](_src/cda5d1e4cf28d2e126f6aefd302e13cc.png)

Каждый сценарий в свою очередь мы можем расшифровать в последовательность действий. Обратите внимание, на UML очень удобно моделировать сразу:

*  действия;
*  объекты, которые в этих действиях участвуют;
*  и кто эти действия выполняет.

Вот так, собирая информацию по дорожкам, получаются очень удобные и красивые диаграммы, которые заказчики хорошо понимают без разъяснения нотации.

![](_src/0a26d99a8639f4c586a12f26a1664c25.png)

Язык UML – расширяемый. Мы не обязаны применять диаграмму вариантов использования только с вариантами использования и с акторами (человечками), мы можем добавить на нее требования – я так делаю всегда, это очень удобно.

## Кейс обработки требований заказчика

Давайте теперь на конкретном кейсе из моей практики пройдем путь, который я обычно прохожу, составляя модель.

Это – реальный кейс. Ниже протокол совещаний заказчика, который поступил в качестве входящих данных. Я оставил в этом протоколе все пункты, которые несут основную смысловую нагрузку.

1.  Базы данных на устройствах, использующиеся для инвентаризации, должны работать автономно (далее – автономные базы), т.е. без подключения к информационной сети организации.
2.  В автономные базы должны выгружаться данные по ОС и номенклатуре, участвующих в инвентаризации.
3.  Необходимо в мобильном приложении отражать состав составного объекта с возможностью отметки считывания штрихкода по составляющей части.
4.  Необходимо протоколировать передачу данных в/из автономных баз в основную базу. Для протокола должна реализована возможность печати.
5.  Необходимо фиксирования в автономных базах в составе данных о наличии объектов учета в соответствии с текущей учетной информацией. В автономной базе должна быть возможность указания составного объекта с указанием его местонахождения.
6.  Необходимо в автономных базах фильтровать учетные данные по местам хранения.
7.  Необходимо по завершению инвентаризации или по требованию пользователей обновить информацию о местонахождении объекта в основной базе.
8.  Необходимо иметь возможность инвентаризации номенклатуры, имеющей количество более 1.

 
И приложение к протоколу:

1. Обеспечить формирование инвентаризационных ведомостей непосредственно в момент проведения инвентаризации, с возможностью:
 *  Контроля даты и времени считывания штрих кода
 *  Контроля излишних, недостающих и неисправных активов
2.  Обеспечить возможность визуального информирования пользователя считывающего штрихкоды информацией параметров считанного актива
3.  Обеспечить возможность поиска в мобильном устройстве
4.  Обеспечить возможность в любое время вывода на экран мобильного устройства данных о проинвентаризированных объектах и оставшихся непроинвентаризированных объектах
5.  Обеспечить возможность при повторном считывании штрихкода получать данные о дате, времени и месте предыдущего считывания штрихкода, с последующим подтверждением или отказом о внесении в инвентаризационные ведомости
6.  Обеспечить синхронизацию программы инвентаризации на мобильном устройстве с основной базой
7.  Обеспечить возможность получения отчета о результатах текущей инвентаризации в %.

Доступ к заказчику был строго регламентирован, возможности уточнять не было, и ситуация на проекте была довольно накаленная, мне сказали: «Делай по этому протоколу».

Как я поступил, чтобы такой протокол обработать:

*  сначала я построил модель и пришел с этой моделью к заказчику, уже переработав протокол;
*  при первичном обсуждении модели заказчик мне дал определенные уточнения;
*  и после этих уточнений мои разработчики сделали систему, которая запустилась с первого раза.

Обратите внимание, у меня не было ТЗ или какого-то формализованного документа. У меня просто была некоторая бумажка, которая определяет хотелки клиента.

Давайте на практике рассмотрим, как я такой протокол обрабатывал.

## Формализация бизнес-процессов в Enterprise Architect

![](_src/523bfa78bb22e5555b270294279529ac.png)

Для формализации бизнес-процессов я использую Enterprise Architect. Это та самая система, про которую мы сегодня общаемся. Я показываю все вживую:

*  в левой части мы видим перечень объектов – это наш Project Browser (обозреватель объектов);
*  и справа будут диаграммы.

Система очень простая, в триальном режиме ее можно бесплатно скачать с сайта разработчика.

![](_src/f1b874b16fa337b4462b3a84ced5b5bb.png)

Первое, что мы делаем – мы формализуем присланный протокол. Для этого вызываем пункт меню Publish – CSV – CSV Import/Export и загружаем файл протокола, сохраненный в csv.

![](_src/1e5cea3d99537a2a7a60bd9aee62ef3c.png)

В пакет «1.1. Требования протокола» загружаем первый csv-файл, а в пакет «1.2. Требования приложения» – второй.

![](_src/12e4e6f68238eedfe8909eb6cfc09a0a.png)

Все наши требования протокола загружены в систему – теперь мы можем с ними работать как с объектами.

![](_src/6741a9246bc268fd923e08e98b2c0434.png)

Мы открываем нашу диаграмму требований протокола, выбираем требования в дереве объектов и копируем их на диаграмму.

Чтобы они на диаграмме выглядели читаемо, изменяем размер одного из требований, приравниваем к нему размер остальных, выравниваем по левому краю и распределяем по высоте диаграммы – система нам все требования расставила.

## Обрабатываем требования протокола

Давайте разберемся с требованиями, которые зафиксированы на первом листе нашего протокола. Мы видим, что у нас в протоколе явно указана цель работы –разработать мобильное приложение для инвентаризации, которое будет передавать информацию в основную информационную базу. Соответственно, нам нужно систематизировать требования к этому мобильному приложению.

Что мы хотим добиться, разбирая этот протокол:

*  во-первых, мы хотим понимать, какие процессы мы автоматизируем;
*  и второе – какие объекты нам для этого нужны (конкретные объекты метаданных).

Это позволит нам перейти от некоторого текстового непонятного описания к конкретике.

![](_src/fd0442e6a65e90a4e9967640029acee1.png)

Рассмотрим первое требование. О чем нам говорит то, что базы данных должны работать автономно? Это значит, что у нас должен быть процесс обмена – сценарий (элемент с типом Use Case) «Обмен данными между основной информационной системой и автономными». Добавляем этот процесс на диаграмму и связываем его с нашим требованием (в группе Requirements Relationships находим пунктирную стрелку и соединяем блок требования с блоком процесса).

![](_src/0549f507bfd6c58845d60b67b6714883.png)

Следующее требование – в автономные базы должны выгружаться данные по ОС и номенклатуре. Это требование у нас также относится к процессу «Обмен данными между основной системой и автономными». Связываем требование с процессом.

![](_src/0712364bcfdcb09618a871db14bffd56.png)

Следующее требование – необходимо в мобильном приложении отражать состав объектов составного объекта с возможностью отметки считывания штрихкода составляющей части. Этот пункт говорит нам о том, что:

*  во-первых, его надо явно учесть в процессе обмена данными;
*  и второе – у нас должен быть какой-то процесс сканирования объектов.

![](_src/47ac3fdecfc1cfb980995f493edc0acd.png)

Смотрите, как интересно. Допустим, сейчас мы с вами работаем с требованиями и хотим понять – мы вообще все требования обработали или не все?

Мы можем открыть матрицу отношений (в меню Design – Matrix – Open as Source).

![](_src/bc026078148840187b12d992a6f68528.png)

Здесь нам нужно выбрать:

*  в качестве источника (Source) – пакет наших требований;
*  а в качестве цели – существующие в системе бизнес-процессы (они у нас сейчас в пакете «2 Состав процессов»).

Смотрите, мы получили матрицу.

*  У нас в левой части требования, с которыми мы работаем.
*  А справа мы видим, с какими процессами эти требования соотносятся, то есть, какие процессы получились из требований.

Кстати, в прошлом году, когда я показывал такую матрицу на выступлении по бюджетированию, меня несколько слушателей отдельно попросили рассказать про Enterprise Architect. Отсюда и родилась идея этого мастер-класса.
 
![](_src/6a1c67a05549993a3ad3a6e100c68ebb.png)

Идем дальше. Четвертое требование – необходимо протоколирование передачи данных из автономной базы в основную. И должна быть реализована возможность печати.

*  Очевидно, что это требование у нас соотносится с процессом обмена (протоколирование).
*  А для процесса печати мы с вами добавляем новый элемент типа Use Case в пакет «2. Состав процессов».

![](_src/6b7935d19e624d966785f0f26dede41e.png)

Новый процесс мы добавляем из набора элементов Use Case (вызывается из меню панели Toolbox). А для требований мы используем набор элементов Requirements.

Обратите внимание, как выбранный набор элементов меняет состав элементов, которые доступны на конкретной диаграмме.

![](_src/dbe3f69e3113b15205834f95237a5370.png)

Здесь можно видеть, сколько нотаций поддерживает Enterprise Architect.

![](_src/0874d8a6208902e32802138a22601cbb.png)

Следующее требование – необходимо фиксировать в автономных базах данные о наличии объектов учета в соответствии с текущей учетной информацией:

* в автономной базе должна быть возможность указания составного объекта с указанием его местонахождения – очевидно, что это опять же касается обмена;
* и при сканировании мы должны указать местонахождение (т.е. делаем привязку к процессу сканирования).

![](_src/0a5d448abfe9c6168938983425d87719.png)

Следующее требование – необходимо в автономных базах делать фильтрацию учетных данных по местам хранения.

* Для этого требования у нас должен быть определенный сценарий «Анализ и поиск объектов». Причем при поиске объектов, очевидно, что дальше мы захотим просканировать найденный объект. Соответственно, у нас сценарии «Сканирование» и «Анализ и поиск объектов» между собой связаны. И эта связь здесь у меня сразу задана как расширяемая («Extend») – у нас есть сценарий поиска объектов и подсценарий в нем сканирования объектов (отмечаем, что эти сценарии связаны).

![](_src/d4730879909615ef1c31f543bda4f53b.png)

 

Следующее требование – необходимо по завершению инвентаризации или по требованию пользователей обновить информацию о местонахождении объекта в основной базе. Очевидно, что это относится к обмену.

И последнее требование – необходимо иметь возможность инвентаризации номенклатуры, имеющей количество более 1. Это требование относится к сканированию.

В результате мы понимаем, какие у нас сценарии. Всего пять минут работы, и мы разобрали уже весьма мутно сформулированные требования. Мы поняли, какие сценарии и процессы будут автоматизированы.

## Обрабатываем требования приложения к протоколу

![](_src/c589eb3fedfcc1d966ed6dc441f639ba.png)

Давайте быстро посмотрим на второй протокол. Все то же самое. Меняем размер одного требования, подгоняем под него размер остальных, выравниваем все по левому краю и распределяем по странице.

![](_src/6a6d04eceb1527fb98306eabe1edf260.png)

Давайте разберемся.

* Первое требование – обеспечить формирование ведомостей непосредственно в момент проведения инвентаризации с возможностью контроля даты и состояния остатков. Это требование связано с процессом «Анализ и поиск объектов». Должна быть какая-то инвентаризационная ведомость, где мы видим все, что просканировали.
* Еще одно требование – обеспечить возможность визуального информирования пользователя, считывающего штрихкоды. Это требование связано с процессом «Сканирование объектов» (причем, при его добавлении сразу появляется расширяемая связь между процессами «Анализ и поиск объектов» и «Сканирование объектов»).
* Следующее требование – обеспечить возможность поиска в мобильном устройстве. Добавляем связь с процессом «Анализ и поиск объектов».

Дальше я уже продолжать не буду. Я думаю, что идею вы поняли. У нас появляется определенный набор сценариев, которые явно связаны с исходными требованиями, и мы можем визуально оценить, какие требования покрыты, а какие не покрыты.

## Добавляем связи на объекты

![](_src/c14b0ce56bfd535de94b8dbc6c43a23d.png)


Дальше – нам нужно от сценариев перейти к конкретным объектам информационных баз.

* Какие объекты системы нам понадобятся для сценария «Обмен данными между информационной системой и автономными базами»?
    * во-первых, нам понадобится обработка «Рабочее место мониторинга обмена»;
    * во-вторых, очевидно, что нам, по всей видимости, понадобится какой-то механизм запуска инвентаризации, чтобы пошел обмен с мобильным устройством – документ «Распоряжение на запуск процесса инвентаризации» копируем сюда же, связываем с процессом, и мы уже видим, что у нас есть определенное распоряжение, которое связано с этим процессом.

* Для сценария «Сканирование» нам, скорее всего, понадобится какая-то обработка сканирования объектов («Обработка сканирования и подбора объектов»).
* И для сценария «Анализ и поиск объектов» нам понадобится «Рабочий стол мобильного приложения».

Вот так мы укрупненно накидываем наши метаданные.

![](_src/c3f33edd9b3985f7d1601d30bb7740b7.png)

Смотрите, наша модель дополняется:

* в первом пакете – наши требования;
* во втором пакете – наш состав процессов;
* дальше мы можем объекты метаданных, которые мы укрупненно накидали при проектировании, разложить по пакету объектов метаданных – у нас появляется почти дерево метаданных. Мы видим в привычном нам дереве те объекты, которые в рамках нашего проекта будут меняться или которые требуют доработок, изменений и т.д.

## Описываем роли с помощью диаграммы Use Case

![](_src/c84d3d520b1fa4c0393c56c97877b6f8.png)

Что мы еще здесь можем получить?

Мы можем спроектировать роли людей, которые будут работать с нашей системой. Я показывал уже эту диаграмму – мы располагаем на отдельной диаграмме все наши бизнес-процессы:

*  говорим, что для запуска процесса инвентаризации нам нужен главный бухгалтер;
*  пользователь автономной системы будет сканировать, искать объекты, заниматься печатью;
*  кроме этого, у нас будет еще один участник процесса, который мы автоматизируем – это «Основная система», которая упоминается в протоколе.

Слева на диаграммах вариантов использования принято изображать непосредственно участников сценария, а справа – внешних участников сценария, к которым этот сценарий обращается:

*  наш сценарий обмена данными обращается к основной информационной системе – поэтому она справа;
*  а человек, который сканирует – он внутри процесса, поэтому он слева.

![](_src/b63bd9966959e5493c7c452b55451636.png)

Дальше мы начинаем уточнять наши требования: у нас есть процесс сканирования объектов. Чтобы его уточнить, мы начинаем расписывать уже конкретный сценарий, строить конкретный порядок действий – последовательность действий, как мы будем работать с этой системой.

![](_src/f2ad1a4ddce858220fbe11d7d34812f8.png)

Мы добавляем для процесса сканирования объектов дочернюю диаграмму.

![](_src/a4197df840f3511416f3b827fe678b3c.png)

Мы поместим наш бизнес-процесс сканирования объектов в отдельную папку «Бизнес-процессы» и начинаем строить нашу модель.

![](_src/47c0325ed3787535d4f67824e6b90b52.png)

Теперь вернемся к диаграмме состава процессов, поставим курсор на элемент «Сканирование объектов». Теперь мы связываем его с диаграммой сканирования объектов (выбираем в контекстном меню New Child Diagram -> Select Composite Diagram -> выбираем диаграмму «Сканирование объектов»).

![](_src/465e109113c4432871ca587a51f1f82f.png)

Теперь на элементе процесса появились «очки», и наша модель становится интерактивной – мы можем от элемента перейти непосредственно к расшифровывающей диаграмме.

Причем, мы с любого места можем перейти к этой расшифровывающей диаграмме. Это очень удобно – модель у нас получается интерактивная, связанная.

![](_src/7756878834cd36dfd35d02681cf544e6.png)

Начинаем строить нашу модель сканирования объектов. Первое, что мы делаем, мы добавляем наши полоски (в контекстном меню диаграммы пункт Swimlanes and Matrix).

![](_src/99f427a5c0dc153b5d598c6a12b4df33.png)

Я обычно добавляю следующие полоски:

*  Вх.вых. (входящая и выходящая информация);
*  Деятельность;
*  Ответственный;
*  и Требования.

Напомню, мы проектируем процесс сканирования объектов. Как выглядит наш процесс сканирования объектов? Нам сначала нужно увидеть, что у нас не просканировано, найти физически то, что
непросканировано, и отсканировать.

![](_src/91ca2b755e9a8ee40503e97d6c279074.png)

Начинаем моделировать. Мы моделируем с помощью диаграммы активности UML. Диаграмма активности – это просто порядок действий.

Добавляем активности:

* начало процесса;
    * поиск непросканированного объекта в МП:
    * очевидно, что у нас есть некоторая обработка, которую мы используем для того, чтобы этот объект найти – мы связываем наше действие и эту обработку;
* сканирование объекта делает пользователь автономной системы – обратите внимание, я на каждой диаграмме использую уже готовый элемент, новых не создаю;
* следующая активность – сканирование;
* связываем наши элементы и завершаем процесс.
* Это очень простой процесс. Я специально его привел для примера. Когда мы с вами были в требованиях, мы набрасывали укрупненные объекты метаданных. Мы еще не могли себе предположить всех наших детальных объектов, которые нам потребуются в этом процессе.


И когда мы с вами расписали процесс сканирования, для нас стало просто очевидно, что при сканировании нужно где-то отметить, зарегистрировать с помощью какого-то объекта базы данных.

![](_src/ad60c9bdaecde349d846b72570f99702.png)

И здесь как раз появляется документ «Регистрация сканирования объекта».

Итак, у нас появился документ сканирования объектов, и теперь можно сказать, что наша модель практически завершена. У нас появились документы, отчеты, обработки – мы уже знаем те границы, в которых мы будем изменять систему, и из чего будет состоять наш проект.

![](_src/17dcb635e09cdce44dac017640489220.png)

Далее – мы начинаем разбираться, все ли требования мы учли в рамках этого процесса сканирования объекта. Мы можем в контекстном меню выбрать пункт Find -> Find in all Diagrams.

![](_src/203af9ba1ab29ede4b6f5cff6028180d.png)

Мы сразу видим, на каких диаграммах представлен этот сценарий. Находим и видим – на диаграмме приложения этим сценарием обеспечивается второе требование, а на диаграмме протокола – третье, пятое и восьмое требование.

Переходим в нашу диаграмму, и копируем в нее все связанные требования.

![](_src/a323da514fa0fc090e71b3de0852f816.png)

Теперь у нас сразу здесь видны и требования, и процессы. И мы можем здесь четко понять, какими объектами метаданных удовлетворены те или иные требования.

![](_src/822828ce292a995c7b17cc6e09e468a7.png)

Дальше здесь можно связать требования с конкретным процессом (вызывав в наборе элементов Activity элемент Dependency), но мы, чтобы не загромождать диаграмму, эту стрелку скрываем (мы ее скрыли, но можем построить матрицу трассировки, как я показывал ранее).

Таким образом, мы не упустим никаких деталей. И пользователь сразу видит, что его протокол требований разложили в процесс, какие связанные объекты для него появились. У нас во всей модели есть сквозной набор элементов, в котором от требований идет связь к конечным объектам метаданных.

## Строим диаграмму Ганта для планирования работ по проекту

![](_src/91c3a8316ef54a1e3c1413c6ea8fbaa6.png)

Смотрите, что самое интересное – у нас появился набор объектов метаданных. Теперь мы можем для этой папки в контекстном меню вызывать View as Gant. У нас появилась диаграмма Ганта. Здесь мы можем вызвать панель назначения ресурсов, добавить аналитика, разработчика.

![](_src/fec5c5fc008e298c618db5ebac29d957.png)

У нас в одной системе сразу и управление требованиями матрицы, и модель, и диаграмма Ганта для того, чтобы спланировать работу по объектам, которые мы уже смоделировали, мы можем назначить ответственных и сделать прикидку плана проекта.

Да, это не MS Project, здесь не так все функционально, здесь нет возможности хранения базовых версий планов, их сравнения и т.д. Но для большинства наших проектов этой функциональности достаточно.

## Генерируем документацию

![](_src/9c5d808f5ae8a69596d3de858c626e66.png)


После того, как мы построили нашу модель, самое интересное – у нас есть требование, есть состав процессов, есть наши объекты метаданных и бизнес-процессы, мы можем сделать какое-то описание наших объектов (например, для документа «Распоряжение на запуск процесса инвентаризации» укажем, для чего предназначен этот документ).

![](_src/41edddc1b8d354e11c287e3d5f92c8c1.png)

И сделаем очень интересную штуку: Publish – Report Builder – Generate Documentation.

![](_src/38dfb884756048f87b88d101abcd4204.png)

Выбираем путь к файлу и нажимаем кнопку Generate.

![](_src/9483a4f19d9e041889396211494ba6c9.png)

## Вопросы:


* Вы показали на примере десятка требований, пары пользователей, нескольких функций и отчетов. А какой в вашем опыте был максимальный объем объектов, которыми вы управляли через Enterprise Architect в какой-нибудь масштабной разработке?
* Наверное, самый масштабный был с несколькими десятками верхнеуровневых требований. По объектам не вспомню. Но они очень здорово по диаграммам бьются. Я специально сделал два пакета, потому что на одну диаграмму, если даже десяток требований вывалить, будет очень непонятно. Вы их просто бьете по пакетам (декомпозируете), и вполне можно работать.
* Как вы предлагаете это использовать в жизни? Для каких целей и задач? В каких контекстах имеет смысл настолько заморачиваться – обеспечить трассировку требований, взаимосвязи, непротиворечивость и еще много чего? Насколько это нужно? Когда внедряется типовая система, идет ее доработка, кастомизация какая-то, и разработчик сильно связан с этой типовой системой – мне кажется, что бесполезно перетаскивать и описывать процессы в первую очередь самой типовой системы. Потому что, если переложить в эту архитектуру ERP (взять и использовать вместо СППР Enterprise Architect) – потом же не разберешься, будет слишком много всего. Мне кажется, Enterprise Architect интересен тогда, когда новые блоки системы создаются практически с нуля – со слабой взаимосвязью с типовой системой. Какой у вас опыт использования Enterprise Architect, когда речь идет о доработке типовой системы и разработке на ее основе?
* Когда я внедряю типовую систему, я в любом случае делаю описание к процессам. Я его делаю в этой нотации. Да, просто модель из двух пакетов: состав процессов и сами бизнес-процессы. Когда мы идем в проект, я всегда делаю описание процессов. Поэтому очень прекрасно ложится
* Но описание процессов – это не все, что вы показывали. Вы показывали еще и связь с объектами метаданных.
* Да, я здесь показал по максимуму, с учетом разработки. Но когда мы делаем описание типовой конфигурации, есть процессы основные – для них нужно делать модель, потому что они вариативные. А есть вспомогательные процессы (например, основные средства) – они у всех одинаковые. Поставьте кружочек, напишите «Учет основных средств» и хватит. А то, где могут быть варианты, потому что одна компания сначала выставляет счет, а потом оформляет заказ. Другая – сначала делает заказ, а потом выставляет счет. Все эти варианты прекрасно описываются в виде процессов.
* Процессы – бесспорно. К тому же для процессов есть нотации более читабельные для заказчика (вроде BPMN). Вопрос – связываете ли вы моделирование с проектировкой системы, когда речь идет о внедрении типовых прикладных решений?
* Когда внедряются типовые решения, доработки все равно возникают. Поэтому мы тут описываем процессы, и здесь же у меня появляются требования, доработки. На текущем проекте мы и требования собрали, и те доработки, которые выявлялись в ходе обсуждения. Мы прямо брали эту модель и обсуждали ее. У меня был отдельный пакет – доработки, которые я выявил, доработки, которые заказчик просил. И отдельный пакет с задачами. Я открываю модель на совещаниях, и мы идем по этой модели – очень удобно было общаться и фиксировать договоренности. Хотя проект был по бюджетированию, там доработок было немного. По поводу диаграммы BPMN – создаете новую диаграмму, указываете, что при ее описании используется набор элементов BPMN2, и рисуете.
* Я правильно понимаю, что опять приходится рисовать, что Activity-диаграммы и диаграммы BPMN живут своей жизнью и автоматически не могут быть трансформированы?
* Нет, мы работаем с диаграммами BPMN вручную, мы их не трансформируем.
* Вы в своей практике не опускаетесь до уровня метаданных, не описываете реквизиты, модули, роли системы?
* Я делаю верхнеуровневое моделирование – ровно так, как я показал.
* Только требования, бизнес-процессы и диаграммы вариантов использования? А проектирование системы вы здесь не выполняете?
* Частично выполняю. У меня есть описанная нотация моделирования, я пробовал опускаться до метаданных, заставлять разработчиков описывать основные алгоритмы. Например, у нас появляется объект метаданных – мы можем описать его функцию. На основании одного объекта метаданных мы можем ввести другой объект метаданных. Мы их можем друг с другом связать по каким-то правилам. Я пробовал это делать. Но для проектов автоматизации типовых внедрений это избыточно. Это долго, дорого и никакой ценности не несет. Когда ты даешь программисту процесс и говоришь: «Я хочу получить этот процесс» – у нас ребята все понимают.
* Как в Enterprise Architect можно отразить отклонения – что не должно быть, но может быть. У меня на каждом шаге, после которого появляется некий материальный результат, он может не появиться. Я могу просканировать – не просканировалось. Я могу начать искать объект – не нашел. Что я должен делать, и как это можно отразить, чтобы можно было понять, к чему эта штука относится? Вы показали прямую дорогу – необходимое и достаточное, если все в порядке. Как это отразить, если не все в порядке?
* Тут есть классическое решение. Добавляем ветку «Не все в порядке» и возвращаемся в начало. Или вы можете добавить сюда еще одну дорожку с названием «Регламент на случай, когда что-то пошло не так» и вставить объект напротив того действия, когда что-то пошло не так. Это не жесткая система, она не обязывает вас выполнять какие-то определенные шаги. Она позволяет построить некоторую нотацию, с помощью которой вы делаете модель вашей системы. Я для себя использую такую нотацию, а вы можете покреативить – сделать для себя отдельную дорожку и покрасить ее элементы в красный цвет, чтобы выделить разрывы.


Данная статья написана по итогам доклада (<a href="https://infostart.ru/video/w1253243/" target="_blank">видео</a>), прочитанного на конференции INFOSTART EVENT 2019. Больше статей можно прочитать <a href="https://infostart.ru/public/prm_iematerials/" target="_blank">здесь</a>.

В 2020 году приглашаем всех принять участие в 7 региональных митапах, а также юбилейной <a href="https://infostart.ru/public/prm_iematerials/" target="_blank">INFOSTART EVENT</a> 2020 в Москве.



 
 
 





